COMMENT ⊗   VALID 00003 PAGES
C REC  PAGE   DESCRIPTION
C00001 00001
C00002 00002	EURISKO and RLL paragraphs for NLM cannibalization
C00010 00003	
C00011 ENDMK
C⊗;
EURISKO and RLL paragraphs for NLM cannibalization
2.5  EURISKO
	  The earlier work on AM led to the conclusion that the ability to
discover powerful new domain-specific heuristics  was a bottleneck in  the
progress of a program which discovers useful new conceptsand relationships
in that  domain.   The EURISKO  project  is  an attempt  to  automate  the
defining, refining, and evaluating of new heuristics.  The primary  source
of power is the fact that heuristics can operate on, inspect,  synthesize,
reason about units, and can thmselves be represented as units.  Thus,  one
heuristic might say "If any unit is  forcing you to keep too many  runtime
statistics, destroy it"; eventually, this  rule might apply to itself  and
suicide.  One  assumption we  are making  is that  most of  the  necessary
heuristics for this task are  general, domain-independent; that is,  there
are very few heuristics specific  to the task of synthesizing  heuristics.
The RLL language is used to represent the tree of heuristics, the  hundred
most general heuristics just below the 7+-2 weak methods.  Knowledge bases
in set  theory, number  theory, programming,  and game  playing are  under
construction; the current goal is to use these to test the efficacy of our
ideas for the heuristic use of heuristic beings.

3.4 RLL
       One valuable tool on the knowledge engineers' workbench in the late
1970's  was  the  "representation   language".   There  were  many   under
development (KRL, FRL, UNITS, KLONE), and they provided the user with many
powerful facilities:   automatic  property inheritance,  hierarchical  and
modular   oraganization   of   knowledge,   attached   procedures,    etc.
Unfortunately, each of these languages embodied its own particular set  of
assumptions, its own set  of allowable inheritance modes,  its own set  of
distinguished slots and subslots; in  short, its own representation.   The
next AI researcher would  come along, peer at  the existing systems,  note
the few fixed features  of each which were  incompatible with his  current
aims, and then resign himself to writing YARL (Yet Another  Representation
Language).  The RLL effort is an attempt  to end this cycle.  It is a  new
representation language,  very  similar  to  UNITS,  which  is  completely
self-described  (e.g.,   there  is   a  unit   for  GET,   for  PUT,   for
TopLevelControl,  for   AnyUnit,  for   the   slot  called   Is-a,   etc.)
Furthermore, there is  a codification of  knowledge about  representation;
for example, there is  an Inheritance unit,  which is the  root of a  tree
taxonomizing known modes  of inheritance.   The user  of RLL  tarts in  an
environment much like UNITS, but can immediately begin to edit units which
discuss active inheritance modes, attached procedures, matching, etc., and
choose (or create) units which together describe an environment similar to
KRL, or  to FRL,  etc.  As  he/she does  so, the  RLL environment  changes
automatically, taking on the  cahracter of the  new description.  This  is
because all  the running  RLL code,  all the  "Lisp", is  really just  the
cached-away result of compiling (in  the automatic programming sense)  the
higher level descriptions (the units).  One feature of RLL which is useful
is its simple grammar for constructing new kinds of slots (e.g., the  user
can define a new unit Aunt as
([Sister of (Mother or Father)] or [Wife of (Brother of (Mother or Father]),
specify that it Is-a Slot, and then ask for the Aunt(Fred).

We are using RLL to consider many of the current issues in  representation
of knowledge.  Often, our solution causes us to add some new capability to
RLL.  For  example, the  distinction between  semantic slots  (how big  is
Clyde) and syntactic ones  (how big is the  unit representing Clyde);  the
ability for  values of  slots to  be  entire units  if there  is  anything
particular to  say  about  them;  the  explicating  of  and  enforcing  of
semantics  (via  range-checking  on  statistics  gathered  dynamically  at
runtime); combining of  function- and object-cenetered  notation, so  that
Aunt(Fred) will  call  Get(Fred  Aunt)  if Aunt  itself  has  no  function
definition,  and  vice   versa;  a   generalization  of   resource-limited
computation, via an extraargument to Get which specifies why the value  is
wanted (IsItNull? RoughSize NeedOneElement,...);  the use of that  feature
to span a continuum of request  types: accept a cached value, recompute  a
fresh value, go out  to disk and rummage  about if required, formulate  an
entire task on an agenda if required; formulate an entire agenda of  tasks
to find out this answer); epistemological status links which specify  what
the justification for the data is (e.g., "believed by Jane").